Celestin Apprentice 5/Apprentice-Release5.iso/Information/CSMP Digest/volume 3/csmp-digest-v3-037

Text File | 1995-12-31 | 63.9 KB | 1,650 lines | [TEXT/R*ch]

C.S.M.P. Digest             Sat, 18 Jun 94       Volume 3 : Issue 37

Today's Topics:

        Finding a drive's SCSI ID
        How to tell which volume was booted from?
        Open Transport & ASLM (Was: Re: ASLM)
        Symantec at WWDC (Was: Symantec vs. Metrowerks? What to do?)
        [Q] Finding out if volume is locked



The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
([e-mail]).

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  If you don't have access to news, you may
still be able to post messages to the group by using a mail server like
anon.penet.fi (mail [e-mail] for more information).

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
nef.ens.fr).  Article threads are not added to the digest until the last
article added to the thread is at least two weeks old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The digest is officially distributed by two means, by email and ftp.

If you want to receive the digest by mail, send email to [e-mail]
with no subject and one of the following commands as body:
    help                        Sends you a summary of commands
    subscribe csmp-digest Your Name    Adds you to the mailing list
    signoff csmp-digest            Removes you from the list
Once you have subscribed, you will automatically receive each new
issue as it is created.

The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest.
Questions related to the ftp site should be directed to
[e-mail]. Currently no previous volumes of the CSMP
digest are available there.

Also, the digests are available to WAIS users.  To search back issues
with WAIS, use comp.sys.mac.programmer.src. With Mosaic, use
http://www.wais.com/wais-dbs/comp.sys.mac.programmer.html.


-------------------------------------------------------

From [e-mail] (jerry halstead)
Subject: Finding a drive's SCSI ID
Date: 27 May 1994 22:49:40 GMT
Organization: University of North Carolina Extended Bulletin Board Service

I am writing a program that uses GetVInfo to get a list of drives the Mac
sees (and snarf information about them) and then a lower level SCSI
routine to go out and find out what drives are on the SCSI chain.  After
getting this info I would like to be able to match the GetVInfo with the
device info I found, determining which drives are Mac supported drives and
which are unformatted or other types of SCSI devices.  Any ideas how to
accomplish this?  Here's what I have so far, first here's the infor from
GetVInfo:

      Drive 9:  Volume Ref: -1;  Bytes free: 92809728, Name: 'Quack'

Then my low level SCSI routine returns the following:

         Device ID: 2
      dev type: 0
              qual: 0
           version: 1
          response: 1
           add len: 31
             vendor: MAXTOR  LXT-340S        6.75
     productId: LXT-340S        6.75
    productRev: 6.75
    data: 45 52 02 00 00 0a 26 38
        00 00 00 00 00 00 00 00
        00 02 00 00 00 40 00 05
        01 01 00 0a 25 fffffff5 00 08 }

I know these two collections of info are the same, but how do I enlighten
my program?  How can I get a drive's SCSI ID by using vRefNum, or how can
I get the name of a Mac drive using low level SCSI routines?  Is there a
handy routine for this, or do I need to learn more about the format of Mac
disks (say it ain't so!).

Tanks!

Oh, btw, the data below productRev is from reading sector zero on the
drive: is there signifigance to the "45 52 02"? I found it on a couple of
Mac drives I was peeking at.
--
- ----------------------------------------------------------------------------
 \ The above does not represent OIT, UNC-CH, laUNChpad, or its other users. /
   ------------------------------------------------------------------------

+++++++++++++++++++++++++++

From [e-mail] (David Shayer)
Date: Sat, 28 May 1994 03:13:44 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

jerry halstead ([e-mail]) wrote:
: I am writing a program that uses GetVInfo to get a list of drives the Mac
: sees (and snarf information about them) and then a lower level SCSI
: routine to go out and find out what drives are on the SCSI chain.  After
: getting this info I would like to be able to match the GetVInfo with the
: device info I found, determining which drives are Mac supported drives and
: which are unformatted or other types of SCSI devices.  Any ideas how to
: accomplish this?

You can match the driver refnum against the scsi id.
See IM 2 p 191 for the formula for calculating the unit table slot
for a driver if you know it's refnum.  See IM 4 p 215 for a list of which
drivers go where in the unit table.  Another case of its obvious if you
had only known to look there.

To summarize IM, scsi drivers go in slots 32-40 in the unit table in
order, so the dirver for scsi 0 is in slot 32, scsi 1 is in slot 1, etc.
slot number = -(refnum-1)
So the driver for scsi 0 has refnum -33, scsi 1 has refnum -34, etc.

: Oh, btw, the data below productRev is from reading sector zero on the
: drive: is there signifigance to the "45 52 02"? I found it on a couple of
: Mac drives I was peeking at.

$4552 is 'ER', the signature in block 0, the driver map.  See IM 5 p 577
for the format of the driver map.  I'd advise against modifying the driver
map, unless you have a backup of your drive, and you intend on testing
the restore option of your backup software.   :-)

David Shayer
[e-mail]
Freelance Hacker


+++++++++++++++++++++++++++

From [e-mail] (Tim Smith)
Date: 28 May 1994 11:37:15 GMT
Organization: University of Washington School of Law, Class of '95

David Shayer <[e-mail]> wrote:
>You can match the driver refnum against the scsi id.
>See IM 2 p 191 for the formula for calculating the unit table slot
>for a driver if you know it's refnum.  See IM 4 p 215 for a list of which
>drivers go where in the unit table.  Another case of its obvious if you
>had only known to look there.

Here's another way, that has the advantage of working even if Apple
stops using a straightforward mapping between refnum and SCSI ID.
Do an illegal command via the SCSI Manager on the SCSI drive whose
Mac driver you wish to find (reading block 0xFFFFFFFF is a good
command here, unless it's a really big drive).  Do not do a
REQUEST SENSE command.  Then, read a block through one of the Mac
drivers.  Now do a REQUEST SENSE via the SCSI Manager to the
disk.  If there is no sense data, then your access through the
Mac driver must have issued a command to that drive, thus wiping
out the sense data from the failed command, and you know that was
the Mac driver for that SCSI device.  If the sense data is still
there, repeat the process, using a different Mac driver next time,
and so on, until you find the right one.

Drawback: this assumes SCSI devices that follow the SCSI spec.  There
are some popular disks out there that don't quite get this right.  In
particular, I seem to recall seeing one that does not clear the sense
data for a failed command when it gets a subsequent command.

Drawback: this is the kind of thing someone might do on DOS (in fact,
that's how some DOS SCSI drivers that load from config.sys determine
what mapping the SCSI BIOS set up from SCSI disks to INT 13h drives),
so your reputation might suffer.

Drawback: this assumes you can control all I/O.  If someone can come in
and do a file access (e.g., perhaps through file shareing?), they may
confuse things.

--Tim Smith

+++++++++++++++++++++++++++

From [e-mail] (Anton Rang)
Date: 03 Jun 1994 00:04:59 GMT
Organization: Minnesota Angsters

In article <[e-mail]> [e-mail] (David Shayer) writes:
> [ about ways to get the scsi id given a volume ]
>
>You can match the driver refnum against the scsi id.
>See IM 2 p 191 for the formula for calculating the unit table slot
>for a driver if you know it's refnum.  See IM 4 p 215 for a list of which
>drivers go where in the unit table.  Another case of its obvious if you
>had only known to look there.

  This works with the old SCSI Manager.  If SCSI Manager 4.3 is
installed, you should call one of its routines instead, as the old
mapping only works for devices visible to the virtual SCSI bus.  I
think it's a "LookupRefNumXref", but haven't got my docs here.
--
Anton Rang ([e-mail])

---------------------------

From [e-mail] (Matthew Paul Cline)
Subject: How to tell which volume was booted from?
Date: 3 Jun 1994 23:55:02 GMT
Organization: University of California, Santa Cruz


    The subject says it all.  Thanks in advance.
--
Poodles have no honor.               Have you hugged your shoggoth today?
GE d? -p+ c++(+++) l++ u++ e+ m+ s/- n+(-) h+ f !g w+ t+ r y+

+++++++++++++++++++++++++++

From [e-mail] (Marshall Clow)
Date: 3 Jun 1994 17:31:48 -0700
Organization: California State University San Marcos

Matthew Paul Cline ([e-mail]) wrote:

>    The subject says it all.  Thanks in advance.

Depends how esoteric you want to get. If you want the current
system volume (almost always the same volume that you booted
from), call SysEnvirons and resolve the wdRefNum for the system
folder into a vRefNum/DirID using GetWDInfo.

If you really want to know what volume was booted from, I think
that you are out of luck. Suppose (System 6, now), you booted from
a floppy, switch-launched to a RAM disk, and unmounted the floppy.

Marshall Clow
Aladdin Systems
mclow@san_marcos.csusm.edu


+++++++++++++++++++++++++++

From [e-mail] (Ivan M CaveroBelaunde)
Date: Sat, 4 Jun 1994 01:56:27 GMT
Organization: The World Public Access UNIX, Brookline, MA

[e-mail] (Marshall Clow) writes:
>Matthew Paul Cline ([e-mail]) wrote:
>>    The subject says it all.  Thanks in advance.
>Depends how esoteric you want to get. If you want the current
>system volume (almost always the same volume that you booted
>from), call SysEnvirons and resolve the wdRefNum for the system
>folder into a vRefNum/DirID using GetWDInfo.
>If you really want to know what volume was booted from, I think
>that you are out of luck. Suppose (System 6, now), you booted from
>a floppy, switch-launched to a RAM disk, and unmounted the floppy.

Actually, that's not quite right. I believe that the vRefNum of the boot
volumes is *always* -1 (it's in a technote somewhere - the same one that
states that the dirID for the root directory of a volumes is always 2).

Hope this helps,

-Ivan
- -
Ivan Cavero Belaunde ([e-mail])
Avid VideoShop Project Lead
Avid Technology, Inc.


+++++++++++++++++++++++++++

From [e-mail] (Grobbins)
Date: 3 Jun 1994 20:07:46 -0700
Organization: Skunkworks

In article <2sofsm$[e-mail]>,
Matthew Paul Cline <[e-mail]> wrote:
>The subject says it all.

No, it doesn't.  At present, the boot disk has a vRefNum of -1.
But that may not be true down the road; indeed, the system may use
some more complex boot mechanisms, perhaps including the use of
servers, volumes in ROM, temporary volumes, or disks made of toasted
raisin bread.  Applications should not generally assume anything about
the boot volume; in particular, it may not be local, may not be
writable, and may not have all of its raisins.

So what is it you are trying to do?  If you can use the call FindFolder
or the application's file spec (from the GetProcessInformation call)
those may provide more reliable information.  For general information
on booting and disk organization, take a look at Inside Mac:Files
p 2-54 and following, and Inside Mac:Devices, ch 4.

Grobbins              [e-mail]

Usual disclaimers apply.


+++++++++++++++++++++++++++

From [e-mail] (Brian Bechtel)
Date: 4 Jun 1994 07:09:13 -0700
Organization: Apple Computer, Inc., Cupertino, California

[e-mail] (Grobbins) writes:

>In article <2sofsm$[e-mail]>,
>Matthew Paul Cline <[e-mail]> wrote:
>>The subject says it all.

>No, it doesn't.  At present, the boot disk has a vRefNum of -1.
>But that may not be true down the road; indeed, the system may use
>some more complex boot mechanisms, perhaps including the use of
>servers, volumes in ROM, temporary volumes, or disks made of toasted
>raisin bread.  Applications should not generally assume anything about
>the boot volume; in particular, it may not be local, may not be
>writable, and may not have all of its raisins.

Augh!  First the Caffeine Manager, now the Toasted Raisin Bread
Manager.... when will it all stop?


Greg's right.  Use FindFolder.

--Brian Bechtel     [e-mail]     "My opinion, not Apple's"

+++++++++++++++++++++++++++

From [e-mail] (Owen M. Hartnett)
Date: Sat, 4 Jun 1994 17:47:36 GMT
Organization: Brown University Department of Computer Science

In article <2sq1u9$[e-mail]> [e-mail] (Brian Bechtel) writes:
>[e-mail] (Grobbins) writes:
>
>Augh!  First the Caffeine Manager, now the Toasted Raisin Bread
>Manager.... when will it all stop?

In the new Universal Headers, both the Caffeine Manager and the Toasted
Raisin Bread Manager fall under the direction of the Grocery Manager.

-Owen


--
Owen Hartnett                [e-mail]
"FAITH, n. Belief without evidence in what is told by one who speaks
        without knowledge, of things without parallel."
            -Ambrose Bierce - The Devil's Dictionary

+++++++++++++++++++++++++++

From [e-mail] (Matthew Paul Cline)
Date: 4 Jun 1994 20:20:39 GMT
Organization: University of California, Santa Cruz


In <2sor62$[e-mail]> [e-mail] (Grobbins) writes:

>In article <2sofsm$[e-mail]>,
>Matthew Paul Cline <[e-mail]> wrote:
>>The subject says it all.


>So what is it you are trying to do?  If you can use the call FindFolder
>or the application's file spec (from the GetProcessInformation call)
>those may provide more reliable information.  For general information
>on booting and disk organization, take a look at Inside Mac:Files
>p 2-54 and following, and Inside Mac:Devices, ch 4.

I am looking for a way to uniquely identify a Mac.  One idea was to  to
use the format time of the boot disk as the Macs ID number.  However,
if identifying a suitable drive will become that complicated, I'll figure
out another way.
--
Poodles have no honor.               Have you hugged your shoggoth today?
GE d? -p+ c++(+++) l++ u++ e+ m+ s/- n+(-) h+ f !g w+ t+ r y+

+++++++++++++++++++++++++++

From [e-mail] (Marshall Clow)
Date: 4 Jun 1994 14:28:59 -0700
Organization: California State University San Marcos

Matthew Paul Cline ([e-mail]) wrote:

>In <2sor62$[e-mail]> [e-mail] (Grobbins) writes:

>>In article <2sofsm$[e-mail]>,
>>Matthew Paul Cline <[e-mail]> wrote:
>>>The subject says it all.


>>So what is it you are trying to do?

>I am looking for a way to uniquely identify a Mac.  One idea was to  to
>use the format time of the boot disk as the Macs ID number.  However,
>if identifying a suitable drive will become that complicated, I'll figure
>out another way.

Why not use the format time for the current system volume? (instead of
the boot volume) It's a lot easier to get!

If the mac has built-in ethernet, then the (hardware) ethernet address
is unique to that machine (NOT the IP address).

Other than that, there is NO foolproof method to uniquely identify a
Macintosh. The creation date for the system disk is a reasonable way
to distinguish macintoshes, but you should plan for failure. In a lab
environment, some sysadmins use disk-cloning software to keep a bunch of
machines' configuration identical. Some of these programs just use SCSI
commands to completely replicate a disk. Every bit. Imagine your software
seeing 50 macs with identical disks, down to the volume's creation date.

Marshall Clow
Aladdin Software
mclow@san_marcos.csusm.edu



+++++++++++++++++++++++++++

From [e-mail] (Jump Long)
Date: 4 Jun 1994 23:35:03 -0400
Organization: America Online, Inc. (1-800-827-6364)

In article <2sofsm$[e-mail]>, [e-mail]
(Matthew Paul Cline) writes:

> How to tell which volume was booted from?

This will give you the name and vRefNum of the current system disk
which (as many have noted) may or may not be the boot volume:

 OSErr result;
 short foundVRefNum;
 long foundDirID;
 Str255 systemDiskName = "\p";
 long freeBytes;

 result = FindFolder(kOnSystemDisk, kSystemFolderType,
kDontCreateFolder,
      &foundVRefNum, &foundDirID);
 if ( result == noErr )
 {
  result = GetVInfo(foundVRefNum, systemDiskName, &foundVRefNum,
&freeBytes);
  if ( result == noErr )
   printf("%#s\n",systemDiskName);
 }

- Jim Luther


---------------------------

From Steve Ethier <[e-mail]>
Subject: Open Transport & ASLM (Was: Re: ASLM)
Date: Wed, 25 May 1994 19:49:08 GMT
Organization: Novell, Inc.

In article <[e-mail]> John McEnerney,
[e-mail] writes:
>[e-mail] (Jim Matthews) writes:
>
>>Me too; fortunately they don't.  OpenTransport has a procedural
interface
>>that can be called from any development system that supports Pascal
>>calling conventions (i.e. any development system that can call the Mac
>>Toolbox).  So I believe it's a true statement that anything you can do
>>today with the driver-based network APIs (.mpp, .atp, .xpp, .ipp) will
be
>>possible under OpenTransport from CodeWarrior.  I don't see any reason
why
>>I shouldn't be able to build an OpenTransport/TCP version of Fetch in
>>CodeWarrior.
>
>If OpenTransport uses a 'pascal' procedural interface and uses ASLM only
>as a DLL solution, then the calling convention/runtime representation
>issue go away. It may be possible to get this to work with CodeWarrior
>with a modest amount of effort. Can someone point me to the proper
>documentation for building for OpenTransport?

Jim and John (and whoever else if following this thread), maybe I don't
understand what is going on with these interfaces, but this is my take on
it.

Apple's implementation of AppleTalk and TCP for Open Transport will
support the old "paramblock" style APIs for backwards compatibility with
existing applications.  In this case, having Open Transport in the ASLM
architecture is really a non-issue.  As far as I know, Open Transport
itself doesn't support the "paramblock" APIs, it is up to the protocol
developer to provide that support (i.e., when I port MacIPX over to Open
Transport, I will have to write additional code in order to support the
existing "paramblock" style MacIPX APIs).

Then, Open Transport provides the X/Open APIs in the following forms:
standard XTI APIs which are procedural interfaces (and really are
synchronous APIs), Apple's superset of the XTI APIs with a procedural
interface (I believe their superset provides async operation, probably
turns them into Pascal interfaces, etc.), and finally, Apple's superset
of the XTI APIs in an object-oriented form.

As I understand it, *all* of the XTI Open Transport interfaces are only
available via ASLM.  Even if you use the procedural XTI interface, you'll
still need to communicate with the ASLM.  Also, from my perspective, I
don't need the OO APIs at this time.  If I could get Metrowerks and
Symantec support of procedural interfaces into Open Transport and the
ASLM, this would make me happy for a while.  At least developers would be
able to use some of the new Open Transport APIs with Metrowerks and
Symantec.

I believe Garry Hornbuckle of Apple is acutely aware of all these issues
and is working on getting them resolved.

Steve Ethier
[e-mail]

+++++++++++++++++++++++++++

From [e-mail] (John McEnerney)
Date: Thu, 26 May 1994 02:49:36 GMT
Organization: The World Public Access UNIX, Brookline, MA


>As I understand it, *all* of the XTI Open Transport interfaces are only
>available via ASLM.  Even if you use the procedural XTI interface, you'll
>still need to communicate with the ASLM.  Also, from my perspective, I
>don't need the OO APIs at this time.  If I could get Metrowerks and
>Symantec support of procedural interfaces into Open Transport and the
>ASLM, this would make me happy for a while.  At least developers would be
>able to use some of the new Open Transport APIs with Metrowerks and
>Symantec.

Someone has kindly volunteered to look into this for me. If there are no
OOP issues and the 'pascal' calling conventions are used, it may be
possible to use the OpenTransport interface from CodeWarrior. (In that
case, although OpenTransport is using ASLM, your program isn't except to
initialize/terminate it) This leaves only issues of importing the
OpenTransport and ASLM .o files--it may not work the first time, but this
is easier to fix than the C++ calling conventions.

Everyone should feel free to keep me posted with new developments.

-- John McEnerney, Metrowerks PowerPC Product Architect


+++++++++++++++++++++++++++

From Steve Ethier <[e-mail]>
Date: Thu, 26 May 1994 17:13:54 GMT
Organization: Novell, Inc.

In article <[e-mail]> John McEnerney,
[e-mail] writes:
>Someone has kindly volunteered to look into this for me. If there are no
>OOP issues and the 'pascal' calling conventions are used, it may be

I didn't volunteer because I don't have the cycles at this time, but if
the kind soul helping you out isn't already familiar with XTI/TLI code, I
do have some test code that I would be willing to share with that person
to jump start the effort.  This code uses TLI (which is very similar to
XTI), so it would take some work to move over to Apple's Open Transport
APIs, but I think Open Transport also supports the XTI APIs, so maybe
this person could just try those interfaces.

The only other drawback to this code is that I think the server side of
it was a NetWare NLM I had also put together.  Of course, this code is 3
years old, so I don't remember exactly how it went together.

Anyway, if this person is interested in seeing this code, please contact
me.

Steve Ethier
Internet: [e-mail]
Phone: [phone]
AppleLink: NOVELL.WCENG (Put [SLE] in the subject so that it'll get
routed to me)

+++++++++++++++++++++++++++

From [e-mail] (Garry Hornbuckle)
Date: 4 Jun 1994 01:06:54 GMT
Organization: Apple Computer

In article <[e-mail]>, [e-mail] (John
McEnerney) wrote:

> Someone has kindly volunteered to look into this for me. If there are no
> OOP issues and the 'pascal' calling conventions are used, it may be
> possible to use the OpenTransport interface from CodeWarrior. (In that
> case, although OpenTransport is using ASLM, your program isn't except to
> initialize/terminate it) This leaves only issues of importing the
> OpenTransport and ASLM .o files--it may not work the first time, but this
> is easier to fix than the C++ calling conventions.

DISCLAIMER: I'm an programmer/software engineer turned marketing guy. I've
written a lot of code in my life, but compilers, linkers, or dynamic
loading architectures are not on my resume. The following comments are
based on someone else's (informed) explanation to me of what the issues are
here. If I screw-up or misstate something here, it's my error.

Apple Shared Library Manager is one of several dynamic link and load
architectures in the Mac OS today (others include the Code Fragment
Manager, the upcoming implementation of System Object Model, the QuickTime
component manager, and the Comm ToolBox). The differences between each of
these, and when to use what, are important discussions...but not for this
thread.

If you possibly can, you should get access to a video or audio tape of the
'94 WWDC session titled "DLLs and Shared Objects on Macintosh" - the first
20-30 minutes of the session was spent explaining key differences between
these technologies and looking at how to pick which one to use for the
specific job at hand.

Almost by definition, DLL architectures need to have some knowledge of code
internals and runtime "stuff". (SOM avoids many of these problems, but
requires you to describe things first in an IDL). During the design and
implementation of ASLM, when it came time to "know things and stuff", ASLM
engineers looked at MPW's behavior as a reference model. Whether this is
good or bad probably depends on what you think about MPW (which is also not
the point of this thread). What is important to know, however, is that
other compiler/linker developers have made choices, for their own very good
and important reasons, to do "things" and store "stuff" differently than
MPW does.

As a result, today ASLM is straightforward to use with MPW, but difficult
or even impossible to use with other compiler/linker tools such as the
MetroWerks or Symantec environments. This is an issue of concern for all
ASLM developers.
Based on what I've been able to understand about this, I believe that there
are five key things that must be true to state that "Compiler XXXX supports
ASLM" or conversely, that "ASLM supports Compiler XXXX". And there are four
different levels of interoperability possible.

Level One Compatiblity
- --------------------
At this level, I can build C or Pascal language programs that use the
services of ASLM and load ASLM shared libaries. The C or Pascal language
programs can be built with the compiler/linker of my choice. The shared
libraries must be built with MPW, or with a compiler/linker that conforms
to all of MPW's "stuff". (A MetroWerks C or Pascal app could use ASLM to
load and share a MPW shared library).

To reach Level One Compatibility, 3 things must be true:

• the Compiler/Linker chosen must be able to import the 'LibraryMgr.o' file
supplied in the ASLM developer kit.

• the Compiler/Linker chosen and ASLM must agree on data representation
issues such as insertion of padding bytes, struct alignment, etc.

This agreement could come because the compiler handles these things the
same way as does MPW (and thus conforms to ASLM's expectation), or possibly
because the compiler offers a switch to conform to MPW conventions as an
option. By itself, having ASLM offer a switch to conform to the compiler's
expectations would not be sufficient to achieve this level of compatibility
(I don't think), because the shared libaries would have been built with MPW
and thus there would potentially be disagreement on this fundamental issue.

•    the Compiler/Linker chosen and ASLM must agree on calling conventions; Is
it going to be C for C, Pascal for Pascal? Pascal for everything?

Again, this agreement could come because the compiler handles these things
the same way as does MPW (and thus conforms to ASLM's expectation), or
because the compiler offers a switch to conform to MPW conventions as an
option. By itself, having ASLM offer a switch to conform to the compiler's
expectations would not be sufficient to achieve this level of compatibility
(I don't think), because the shared libaries would have been built with MPW
and thus there would potentially be disagreement on this fundamental issue.

Level Two Compatibility
- ---------------------
At this level, I can also build C++ programs that use the services of ASLM
and load ASLM shared libaries. The C++ programs can be built with the
compiler/linker of my choice. The shared libraries must be built with MPW,
or with a compiler/linker that conforms to all of MPW's "stuff". (A
MetroWerks C++ app could use ASLM to load and share a MPW shared library).

To reach Level Two Compatibility, all three conditions from Level One must
be satisfied. In addition, the following condition must also be true:

• the Compiler/Linker chosen and ASLM must agree on the V-table format in
use.

This agreement could come because the compiler handles these things the
same way as does MPW (and thus conforms to ASLM's expectation), or because
the compiler offers a switch to conform to MPW conventions. By itself,
having ASLM offer a switch to conform to the compiler's expectations would
not be sufficient to achieve this level of compatibility (I don't think),
because the shared libaries would have been built with MPW and thus there
would potentially be disagreement on this fundamental issue.

Level Three Compatibility
- -----------------------
At this level, I can also build shared libraries that can be loaded by ASLM
upon direction from a client application. The client application and the
shared libaries can be built with THE SINGLE compiler/linker of my choice.
(A MetroWerks C, Pascal, or C++ application could use ASLM to load a
MetroWerks shared library).

To reach Level Three Compatibility, all four conditions from Level One and
Level Two must be satisfied. In addition, the following condition must also
be true:

• the Compiler/Linker chosen and ASLM must agree on the format of the
object file.

This agreement could come because the compiler handles these things the
same way as does MPW (and thus conforms to ASLM's expectation), or because
the compiler offers a switch to conform to MPW conventions, _or_ by having
an ASLM switch that directs ASLM to conform to the compiler's expectations
for "stuff".

Level Four Compatibility
- ----------------------
At this level I can build C, Pascal or C++ client applications, as well as
shared libraries that can be loaded by ASLM upon direction from a client
application. The client application and the shared libaries can be built
with a MIX-AND-MATCH set of compilers/linkers of my choice. Libraries, both
procedural and object-oriented, from multiple compilers could be
dynamically loaded and shared. (A MetroWerks main could load a shared
library that had been built with Symantec tools, for example).

To reach Level Four Compatibility, all five conditions from Level One
through Level Three must be satisfied. In addition, the following condition
must also be true:

• ALL Compilers/Linkers and ASLM must agree on ALL the "stuff" outlined
above.

This agreement, I believe, could only come through an industry or defacto
standard representation and format for data, calling conventions, V-table
formats, and object file formats. To my knowledge, no such single format
agreement, spanning MPW, MetroWerks, and Symantec tools, exists (I'd love
to be wrong on this).

- ----------------------

I really appreciate the support for and interest in ASLM by applications
and tool developers such as the great folks at MetroWerks and Symantec. I'm
interested in working out multi-tool support for ASLM, and am willing to
seriously investigate changes to ASLM if there is a real possibility of
getting to Level Four compatibility!

Comments and corrections are welcome. But please, no technical flames. I'm
only the marketing guy. ;)


Garry "also the ASLM guy" Hornbuckle

- ---------------------------------------------------------------------
Garry Hornbuckle        Product Manager, Communications & Collaboration
- ---------------------------------------------------------------------
"If I told you that I   | email      [e-mail]
 spoke only for myself  | applelink  HORNBUCKLE1
 would you believe me?" | fax        [phone]
- ---------------------------------------------------------------------

---------------------------

From [e-mail] (John Cooper)
Subject: Symantec at WWDC (Was: Symantec vs. Metrowerks? What to do?)
Date: Sun, 22 May 1994 13:55:55 GMT
Organization: Vivid Technologies Inc.

In article <2ren5c$[e-mail]> [e-mail] ([e-mail]) writes:
>> A couple of more things.  First, today, Symantec has announced some
>> new tools -- a subscription CD that has development versions of
>> compilers and such on it.
>Hehehe...  I wonder where they got *that* idea.  But are Symantec's
>prereleases as stable as Metrowerks? Can you post some more details,
>or at least the month of the MacTech issue reviewing this CD? Symantec
>folks, you guys want to post some details? Phil? Tom?

   I heard from a friend who attended WWDC that Symantec was boo'ed and
hissed at by a room full of developers during a seminar. Such a reception
is usually reserved for Microsoft alone...

   This same friend also characterized Symantec's tools announcements as
mostly: "We'll have that too, someday..." I guess developers weren't too
impressed with Symantec this year.

   Can anyone else who attended offer their observations/opinions/insights?

-John

+--------------------------+------------------------------------------+
| John R. Cooper           | Internet: [e-mail],               |
| Vivid Technologies, Inc. |           [e-mail]          |
| Waltham, MA 02154        | AOL:      JRCooper ([e-mail])    |
+--------------------------+------------------------------------------+
| "God split himself into a myriad parts that he might have friends." |
| This may not be true, but it sounds good and is no sillier than any |
| other theology.                                                     |
|                        -- Long's Notes --                           |
+---------------------------------------------------------------------+

+++++++++++++++++++++++++++

From [e-mail] (Michael W. Wellman)
Date: Mon, 23 May 1994 13:38:57 -0500
Organization: InterCon Systems Corp., Herndon, VA, USA

In article <[e-mail]>, [e-mail] (John
Cooper) writes:
>    I heard from a friend who attended WWDC that Symantec was boo'ed and
> hissed at by a room full of developers during a seminar. Such a
> reception is usually reserved for Microsoft alone...
>
>    This same friend also characterized Symantec's tools announcements
> as mostly: "We'll have that too, someday..." I guess developers
> weren't too impressed with Symantec this year.
>
>    Can anyone else who attended offer their observations/opinions/
> insights?

Symantec was repeatedly hissed at WWDC.  Essentially, every time Apple
mentioned their respective names during the "Developer Tools State of the
Union", Symantec was hissed and Metrowerks was applauded.

When it came time to do their presentations, Metrowerks blew everyone away.
Their demo consisted of their compiling the 68k version of Metrowerks, the
PowerPC version of Metrowerks, and MacApp 3.1; some 1.4 million lines of code
in some 11 minutes (in fact, the talking portion of the presentation finished
first so they stopped the compile before it all finished, but they were only
a few files from the end of MacApp).  This was followed by testimonials from
people from Adobe, Apple, Claris, and other companies.  Summary of the
testimonials:  Metrowerks not only cures cancer, it causes world peace.

By the time Symantec took the stage, no one was booing anymore simply because
everyone felt sorry for them.  They decided not to compile, not to show the
debugger, and when they went to show some of their "cool" stuff, it
repeatedly crashed.

To be fair, Symantec had added some nifty features to both their 7.0.1
release and their next generation environment.  You can finally open a file
without a project being open; you can open multiple projects; projects can be
nested nicely in the project window and double-clicking them opens another
project window; they support descending sub-projects and automatically
rebuilding them if necessary; they've got multiple-paned windows; etc.

The consensus seemed to be too little too late.

Personally, three of the five people I was with left immediately after the
Metrowerks demo to buy a copy of Metrowerks and see if we could get some
things compiled before dinner... ;-)

I'm personally disappointed that both Metrowerks and Symantec seem pretty
dedicated to not supporting Apple's Shared Library Manager since you can't
use Open Transport without such support.

mikel





+++++++++++++++++++++++++++

From [e-mail] (Matt Mora)
Date: 23 May 94 23:10:26 GMT
Organization: SRI International, Menlo Park, CA

In article <[e-mail]> [e-mail]
(Michael W. Wellman) writes:

>I'm personally disappointed that both Metrowerks and Symantec seem pretty
>dedicated to not supporting Apple's Shared Library Manager since you can't
>use Open Transport without such support.


Or that the OpenTransport team decided to use ASLM.



Xavier





--
___________________________________________________________
Matthew Xavier Mora                       [e-mail]
SRI International                       [e-mail]
333 Ravenswood Ave                    Menlo Park, CA. 94025

+++++++++++++++++++++++++++

From [e-mail] (Jon W‰tte)
Date: 24 May 1994 06:17:50 GMT
Organization: The Royal Institute of Technology

>>I'm personally disappointed that both Metrowerks and Symantec seem pretty
>>dedicated to not supporting Apple's Shared Library Manager since you can't
>>use Open Transport without such support.

>Or that the OpenTransport team decided to use ASLM.

Won't ASLM come on top of the CFM? And both MW and SC will of course
support the CFM. The only thing left is making the name mangling
conform to CFront standards.

Cheers,

                    / h+
--
 -- Jon W{tte, [e-mail], Mac Software Engineer Deluxe --

  "From now on I will re-label the EQ on the deck as Fizz and Wobble
   instead of HF and LF."

+++++++++++++++++++++++++++

From Chris Hanson <[e-mail]>
Date: Mon, 23 May 94 22:53:26 -0600
Organization: Green Dragon Creations, Inc.


In article <[e-mail]>, Michael W. Wellman
writes:

> I'm personally disappointed that both Metrowerks and Symantec seem pretty
> dedicated to not supporting Apple's Shared Library Manager since you can't
> use Open Transport without such support.

I think it's more Apple's fault, actually.  Shared Library Manager is designed
to work with MPW C++ (which is CFront 2.something, I think).  This is because
it explicitly supports only C++, and relies on the structure of MPW's virtual
tables and the way MPW munges method names.  Of course, since Apple has
committed to SOM I think they'd be stupid not to support Open Transport on it
also.  My bet is that they will; until SOM support is formally integrated into
the OS, we'll probably rely on ASLM for such matters.

TTFN,
Chris

+++++++++++++++++++++++++++

From [e-mail] (Michael W. Wellman)
Date: Tue, 24 May 1994 09:37:02 -0500
Organization: InterCon Systems Corp., Herndon, VA, USA

I wrote:
> > I'm personally disappointed that both Metrowerks and Symantec
> > seem pretty dedicated to not supporting Apple's Shared Library
> > Manager since you can't use Open Transport without such support.

Chris Hanson <[e-mail]> wrote:
> I think it's more Apple's fault, actually.  Shared Library Manager is
> designed to work with MPW C++ (which is CFront 2.something, I
> think).  This is because it explicitly supports only C++, and relies
> on the structure of MPW's virtual tables and the way MPW munges
> method names.  Of course, since Apple has committed to SOM I think
> they'd be stupid not to support Open Transport on it also.  My bet is
> that they will; until SOM support is formally integrated into the
> OS, we'll probably rely on ASLM for such matters.

I vaguely recall something about SOM not being capable of dealing with issues
such as interrupts (you pay some prices for platform independence).  If this
memory is correct, it'd be very hard to build a networking structure on top
of it.

Also; in Apple's defense (or, more directly, in the Open Transport team's
defense), I don't believe SOM was available as an option when ASLM was
implemented.

Both Metrowerks and Symantec stated that it was the vtable dependencies that
made them not want to do the work, that they've spent a lot of time
optimizing their compilers to generate more efficient vtables, and that they
didn't want to spend still more time making them less efficient.

All of the issues make sense; but it's inconvenient having to give up
Metrowerks because of this (clearly, if Open Transport needs ASLM, I'm not
giving up ASLM).

mikel





+++++++++++++++++++++++++++

From [e-mail] (William Edward Woody)
Date: 24 May 1994 18:08:55 GMT
Organization: California Institute of Technology, Alumni Association

Michael W. Wellman <[e-mail]> wrote:
>I'm personally disappointed that both Metrowerks and Symantec seem pretty
>dedicated to not supporting Apple's Shared Library Manager since you can't
>use Open Transport without such support.

Call me stupid (having zero experience with ASLM), but on my E.T.O. #14
disk there's this directory (E.T.O.:Tools - Objects:Apple Shared Libary
Manager:ASLM 1.1.GM:ASLM Symantec Support) containing stuff which reportedly
allow you to develop and use ASLM with both Symantec C++ for MPW and
Symantec C++ for Macintosh v6.0.1.

                        - Bill
--
 "A secret face--a touch of grace        William Edward Woody
  A man must learn to give a little space    [e-mail]
  A peaceful state--a submissive trait
  A man must learn to gently dominate" -- Rush, "Animate"

+++++++++++++++++++++++++++

From [e-mail] (John McEnerney)
Date: Tue, 24 May 1994 21:11:09 GMT
Organization: The World Public Access UNIX, Brookline, MA

[e-mail] (Michael W. Wellman) writes:

>Both Metrowerks and Symantec stated that it was the vtable dependencies that
>made them not want to do the work, that they've spent a lot of time
>optimizing their compilers to generate more efficient vtables, and that they
>didn't want to spend still more time making them less efficient.

In order to support ASLM, every aspect of our C++ implementation would
need to be identical to MPW cfront (on 68K) and PPCC (on PowerPC). This
gives us very little latitude in improving calling conventions, vtables
formats, name mangling, etc. all to support an interface which makes up
at most 1% of your program. Seems like a heavy price to pay. (Which is
not to say our current implementation is more efficient at the moment,
but we'd certainly like it to continue optimizing it)

Furthermore, we'd need to generate MPW .o files on 68K and XCOFF files on
PowerPC so that the ASLM tools could do their pre- and post-processing.
This would require again a substantial amount of work which is better
spent improving our code generation, implementing templates, etc.

SOM solves many of these issues because it reduces the C++ interface to a
C interface, and it is much easier to be compatible with that (we already
are on PowerPC, will be soon on 68K)

>All of the issues make sense; but it's inconvenient having to give up
>Metrowerks because of this (clearly, if Open Transport needs ASLM, I'm not
>giving up ASLM).

Take this up with the Open Transport engineers. It was a shortsighted
decision to use a technology supported only by Apple's tools. I can't
believe that it was impossible to implement the necessary functionality
without component C++ objects in ASLM shared libs.

We are working closely with Apple to support SOM and CFM (PowerPC and 68K).

-- John McEnerney, Metrowerks PowerPC Product Architect


+++++++++++++++++++++++++++

From [e-mail] (Matt Mora)
Date: 24 May 1994 16:07:01 -0700
Organization: SRI International, Menlo Park, CA

In article <[e-mail]> [e-mail] (John McEnerney)
writes:

>Take this up with the Open Transport engineers. It was a shortsighted

I did and he wasn't very happy about it. I guess I touched a raw nerve
but Garry Honbukle was very defensive about it. Oh well, looks
like I won't be doing any opentransport stuff anytime soon. Good
thing they are not going to break the old API.


>We are working closely with Apple to support SOM and CFM (PowerPC and 68K).

I agree with John. It seem like a much better way to go.



Xavier



--
___________________________________________________________
Matthew Xavier Mora                       [e-mail]
SRI International                       [e-mail]
333 Ravenswood Ave                    Menlo Park, CA. 94025

+++++++++++++++++++++++++++

From [e-mail] (Zalman Stern)
Date: Wed, 25 May 1994 01:52:08 GMT
Organization: Adobe Systems Incorporated

Jon W tte writes
> Won't ASLM come on top of the CFM? And both MW and SC will of course
> support the CFM. The only thing left is making the name mangling
> conform to CFront standards.

Does ASLM depend on vtable layout? Perhaps the real answer is to standardize
the whole C++ runtime to such a level that objects created by different
compilers can be linked together. (What? Don't make you laugh so hard? MY
apologies :-))
--
Zalman Stern           [e-mail]            [phone]
Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900
   Never let a "final candidate" subscript get above the age of consent.

+++++++++++++++++++++++++++

From [e-mail] (John McEnerney)
Date: Wed, 25 May 1994 07:06:07 GMT
Organization: The World Public Access UNIX, Brookline, MA

[e-mail] (Zalman Stern) writes:

>Does ASLM depend on vtable layout? Perhaps the real answer is to standardize
>the whole C++ runtime to such a level that objects created by different
>compilers can be linked together. (What? Don't make you laugh so hard? MY
>apologies :-))

While at Symantec I spent some time looking into all of the issues
involved in supporting ASLM in the THINK compilers. I recall that ASLM
exports an OOP interface to the many worthwhile features that it
provides. This means that if you need to use any of these features, the
code on the client side had better have the same naming conventions,
vtable formats, and calling sequences as the code in the ASLM library.

There are other problems, such as tools which process the .o files output
from the MPW compiler, though these may go away once CFM is universally
supported.

However, the issue of compatible conventions doesn't go away. If a
library exports an OOP interface, via ASLM or CFM, it would require that
all compilers use the same conventions. SOM works around this by
generating C++ wrappers to a C interface--your source code is in C++, but
by the time a vtable is constructed or a virtual function is called, it
has been reduced to simple C data structures and calling conventions.

I admit to never having looked into the exact requirements of Open
Transport. I'll try to do some reading on it to see if a solution
specific to Open Transport is possible.

-- John McEnerney, Metrowerks PowerPC Product Architect


+++++++++++++++++++++++++++

From [e-mail] (Leon Lambert)
Date: Wed, 25 May 1994 19:16:13 GMT
Organization: measurex

I'd like to thank John McEnerney from Metrowerks for taking
an interest in this discussion. I haven't noticed Symantec even
talking about it.


Let's all just get along :)

+++++++++++++++++++++++++++

From [e-mail] (Jon W‰tte)
Date: 26 May 1994 17:56:45 GMT
Organization: The Royal Institute of Technology

>> I'm personally disappointed that both Metrowerks and Symantec seem pretty
>> dedicated to not supporting Apple's Shared Library Manager...

>Can you expand on this?  What stands in the way of using Metrowerks to
>do ASLM work?  (Particular language features?).

ASLM relies on CFronts name mangling and vtable formats.

Case closed. :-)

>meantime I'd like to get some small OpenDoc parts built and the only
>compiler I have here is CodeWarrior.  (I've also own the current rev of

No Can Do unless you a) replace ASLM or b) wait for the CFM/SOM version
due Any Year Now.

--
 -- Jon W{tte, [e-mail], Mac Software Engineer Deluxe --
   This sig is less than 3 lines: Improve the UseNet S/N ratio!

+++++++++++++++++++++++++++

From [e-mail] (Peter N Lewis)
Date: 27 May 1994 07:42:43 +0800
Organization: NCRPDA, Curtin University

[e-mail] (John McEnerney) writes:

>[e-mail] (Zalman Stern) writes:

>I admit to never having looked into the exact requirements of Open
>Transport. I'll try to do some reading on it to see if a solution
>specific to Open Transport is possible.


Garry says that SOM can't be used for Open Transport.  I don't know why,
but I do know that one of thse has to happen:

- Metrowerks supports ASLM in their Pascal compiler (seems quite unlikely).
- Symantec supports ASLM in THINK Pascal (fat chance!)
- Open Transport moves to SOM (Garry says this is impossible)
- Dylan supportsd ASLM and I move to it.

Or I could just find a new area on the Mac to work on....
    Peter.
--
I'm at a conference (WWDC) and on holiday until June 1, so my messages
will be short, delayed, imprecise, and less helpful than usual.  Sorry!
Peter N Lewis <[e-mail]>       Ph: [phone]

+++++++++++++++++++++++++++

From [e-mail] (Chris DeSalvo)
Date: Sat, 28 May 1994 06:43:16 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

Back the original thread:  No, Symantec wasn't booed and hissed that
badly.  There was a little, but it wasn't TOO much.  Yes, their TCL
2.0 Demo (which was very simple) crashed.  But so did the first demo
of OpenDoc during the opening Keynote address.

In Symantec's favor:  They threw the most awesome party of the
convention!  It was at Gordon Biersch, a local bar/brewery.  The
fresh-brewed beer and the food were all awesome.

In regards to ASLM and it's dependency on CFront conventions:
I just read today that Apple has made an agreement with Symantec to do
a technology trade and get their compiler front-end, abandoning the
CFront stuff in the process.

Anyone wanna venture a speculation of what this means for future
development?  Also, I do recal in one of the WWDC sessions Apple
saying something to the effect that althrough a lot of the libraries
for the new technologies was OO-oriented, you didn't have to use an
OOPL to utilize them.  Anyone recall this, or was I too hung-over?

L8R
Chris
--
+-----------------------------------------------------------------+
| [e-mail]           |   Macintosh:  Changing the world, |
| Chris De Salvo              |        one person at a time!      |
| Professional Mac Geek       |    -----------------------------  |
| for MacPlay, Inc.           |      (I wish they'd hurry up!)    |
+-----------------------------------------------------------------+

Any opinions expressed, or implied, are my own!  They should not be
considered representative of the opinions or policies of my employer,
MacPlay, a division of Interplay Productions, Inc.

+++++++++++++++++++++++++++

From [e-mail] (Stephan Somogyi)
Date: Mon, 30 May 1994 20:37:18 GMT
Organization: Digital Media

In article <2s3c5j$[e-mail]>, [e-mail]
(Peter N Lewis) wrote:

> Garry says that SOM can't be used for Open Transport.  I don't know why,
> but I do know that one of thse has to happen:

If memory serves, the reasons are that SOM isn't interrupt-safe and the
overhead incurred by SOM makes it unsuitable for time-critical code such
as a protocol stack.

____________________________________________________________________________
Stephan Somogyi             Vorsprung durch Technik            Digital Media

+++++++++++++++++++++++++++

From [e-mail] (Stephan Somogyi)
Date: Mon, 30 May 1994 20:45:16 GMT
Organization: Digital Media

In article <[e-mail]>, [e-mail]
(Michael W. Wellman) wrote:

> All of the issues make sense; but it's inconvenient having to give up
> Metrowerks because of this (clearly, if Open Transport needs ASLM, I'm
> not  giving up ASLM).

After talking to several people at WWDC about this, I'm not convinced that
things are quite this bleak.

OpenTransport will have a C-based procedural interface that one could
(theoretically -- I haven't looked into this yet myself) write one's own
C++ wrappers around. However, I don't know whether there are any penalties
for using the C-based interfaces rather than the C++ interfaces.

To the best of my knowledge, the issues surrounding support of ASLM (and
the resultant requirements for compatible name mangling and vtable
formats) are only relevant if one wants to use OpenTransport's C++
interfaces.

____________________________________________________________________________
Stephan Somogyi             Vorsprung durch Technik            Digital Media

+++++++++++++++++++++++++++

From [e-mail] (Amanda Walker)
Date: Thu,  2 Jun 1994 15:48:32 -0500
Organization: InterCon Systems Corporation, Herndon, VA  USA

[e-mail] (Stephan Somogyi) writes:
> OpenTransport will have a C-based procedural interface that one
> could (theoretically -- I haven't looked into this yet myself) write
> one's own C++ wrappers around. However, I don't know whether there are
> any penalties for using the C-based interfaces rather than the
> C++ interfaces.

The C++ class is, in fact, simply a wrapper around the C interface, as far as
I can tell.

> To the best of my knowledge, the issues surrounding support of ASLM
> (and the resultant requirements for compatible name mangling and
> vtable formats) are only relevant if one wants to use OpenTransport's
> C++ interfaces.

You still need at least minimal ASLM support in order to use the C API, since
it's an ASLM function set, not a statically linked library.  Also, the
LibraryManager.o library needs to have its vtables set up and constructors
called, which necessitates at least a simulacrum of the MPW C++ initialization
code.

The basic problem is that the ASLM is a hack (albeit a very clever hack).  It
will thus require a hack to access it from Code Warrior.  The only question is
how twisted such a hack will turn out to be.  Also note that this is only a
big problem on the 68K side.  The PPC ASLM is built on top of CFM, which
should help a lot.  Unfortunately, Open Transport seeds have been 68K-only
builds so far.

None of this is intractable by any means.  It's just annoying :).


Amanda Walker
InterCon Systems Corporation





+++++++++++++++++++++++++++

From [e-mail] (Pete Mackie)
Date: Sat, 4 Jun 1994 15:52:56 GMT
Organization: Seaquest Software

In Article <[e-mail]>,
[e-mail] (Stephan Somogyi) wrote:
>In article <2s3c5j$[e-mail]>, [e-mail]
>(Peter N Lewis) wrote:
>
>> Garry says that SOM can't be used for Open Transport.  I don't know why,
>> but I do know that one of thse has to happen:
>
>If memory serves, the reasons are that SOM isn't interrupt-safe and the
>overhead incurred by SOM makes it unsuitable for time-critical code such
>as a protocol stack.
>

I also heard that SOM isn't interrupt-safe at WWDC therefore cannot be used
for Open Transport.  However, Apple states that my not always be true.  See
Apple's DDL Statement of Direction following.  This may help you, or confuse
you even more.   ;-)

==========================================
Macintosh Dynamic Linked Libraries (DLLs)
==========================================
ETO #14 (March '1994) Update

Apple has developed a complete technology solution for shared code, shared
objects, and dynamic linked libraries (DLLs) on the Macintosh. Parts of this
solution are available today, with additional parts becoming available in
the coming months.

There are three key components to Macintosh DLL strategy:
    o Apple's Shared Library Manager (ASLM),
    o Apple's Code Fragment Manager (CFM), and
    o IBM's System Object Model (SOM).

Here is a brief summary of ASLM, CFM, and SOM ...

ASLM
- ----------
Apple Shared Library Manager is the first component of Apple's DLL solution
to be available, and is an integral part of our overall DLL offering.  ASLM
supports shared code libraries for both procedural and object oriented
development efforts. A number of Apple products have already been based on
ASLM, including MacSNMP and the GeoPort communications pod technology. Third
parties such as Microsoft (OLE for Macintosh), Novell (AppWare), and Aldus
have also adopted ASLM to support their DLL needs.

In the future, additonal functionality will be added to the Macintosh
operating system as ASLM libraries, including our next generation
networking, the Open Transport Communications Architecture.

ASLM v1.1.1 is the currently shipping release. ASLM v2.0 is under
development, to provide support for native code shared libraries on Power
Macintosh (An alpha release is available on this ETO). ASLM 2.x sits on top
of (is based on) the Code Fragment Manager. This work is expected to produce
final product in 2Q CY94.

As CFM becomes available on 68K Macintosh (see below), ASLM version 2.1 will
support CFM on 68K as well, while continuing to support current 68K-style
shared libraries. Thus,
ASLM v2.x will provide compatibility for ASLM v1.1 and v1.1.1 applications.

ASLM adds higher-level object-oriented capabilities to the environment that
are not a part of the Code Fragment Manager itself. ASLM is the technology
of choice when you:

    o need DLLs on 68K today ... ASLM is shipping
    o want simplicity and elegance with C++
    o want a simple but powerful extension mechanism using C, Pascal, or ASM
    o have performance sensitive (i.e., interrupt time) needs like networking
    o want run-time transparent dynamic loading and unloading of code
    o DON'T need transparent access to per-context global data
    o DON'T need to solve the "fragile base class" problem for C++

CFM
- ----------
As a second key step in our DLL strategy, Apple has developed a new
foundation layer for dynamic linking on the Macintosh known as the Code
Fragment Manager (CFM). CFM will be a core part of System Software on the
PowerPC Macintosh.

CFM is also being developed for the Macintosh on 68K. This work is expected
to produce final product in 3Q CY94.

The Code Fragment Manager provides code sharing and dynamic linking, with
features supporting per-context globals. CFM will be fully supported by
development tools on Macintosh.

CFM is the best bet when your application:
    o runs on PowerPC Macintosh first, and 68K Macintosh later
    o needs only basic dynamic loading and unloading of shared code
    o needs to reduce system overhead to the minimum amount
    o needs transparent access to per-context global data
    o DOES NOT need system-level OOP support


SOM
- ----------
Apple is in the process of licensing and porting IBM's System's Object Model
(SOM) technology to Macintosh. SOM is a multi-platform standard providing
for system-level sharable objects in a language-neutral way. SOM also solves
the "fragile base class" problem, avoiding the need for client libraries to
be recompiled when the base class they inherit from is in a different
library and is changed.

To offer these benefits (multi-platform support and fragile base-class
resolution) SOM requires the use of an IDL as a first step in the
development process.

SOM runs on top of CFM, and thus will become available on both 68K and
PowerPC Macintosh.

SOM is a foundation technology for OpenDoc.


Integration
- ----------
SOM and ASLM will both live in a CFM run-time environment, and will both be
available on both 68K and PowerPC Macintosh. Thus there will be no
impediment to co-existence of ASLM and SOM, or to applications that use both
ASLM and SOM. In fact, a SOM class could easily call an ASLM class or
vice-versa.

Over time, some of the functionality provided by ASLM may be supplanted by
SOM. However, ASLM APIs will be preserved. As a result, applications written
to the ASLM API may have some functionality transparently migrated to SOM in
the future.




___________________________________________________________________
Pete Mackie                  |       Internet: [e-mail]
Seaquest Software            |      AppleLink: D0937
Portland, Oregon  USA        | America Online: Seaquest1
Voice: [phone]        |         eWorld: Seaquest
Fax:   [phone]        |
_____________________________|_____________________________________

---------------------------

From [e-mail] (Roland Kwee)
Subject: [Q] Finding out if volume is locked
Date: 2 Jun 1994 19:13:15 -0700
Organization: (none)


How do I quickly check if the volume is locked? New Inside Mac, Files,
p2-8 says I should check that before opening a file for write access,
because the file open call would return OK even on locked volumes.
They recommend calling PBHGetVInvo() (what a user-friendly system...)
which is described on p. 2-144, but I can't find the description
of the volume attributes ioVAtrb.

Does anybody know?

Thanks, Roland Kwee
(please send email directly to: [e-mail])

+++++++++++++++++++++++++++

From [e-mail] (Marshall Clow)
Date: 2 Jun 1994 19:26:29 -0700
Organization: California State University San Marcos

Roland Kwee ([e-mail]) wrote:

>How do I quickly check if the volume is locked? New Inside Mac, Files,
>p2-8 says I should check that before opening a file for write access,
>because the file open call would return OK even on locked volumes.
>They recommend calling PBHGetVInvo() (what a user-friendly system...)
>which is described on p. 2-144, but I can't find the description
>of the volume attributes ioVAtrb.

>Does anybody know?

Here's my routine:

Boolean    VIsLocked ( short vRefNum ) {
#define    softLockBit        0x8000
#define hardLockBit        0x0080

    OSErr            err = noErr;
    HParamBlockRec    pb;
    Str255             vName;

    if ( vRefNum == kOnSystemDisk )
        vRefNum = FindSystemVolume ();

    vName [ 0 ] = '\0';
    pb.volumeParam.ioCompletion    = nil;
    pb.volumeParam.ioNamePtr    = vName;
    pb.volumeParam.ioVRefNum    = vRefNum;
    pb.volumeParam.ioVolIndex    = 0;
    err = PBHGetVInfoSync ( &pb );
    AssertStr ( err == noErr, "\pPBHGetVInfoSync in VIsLocked" );

    return ( pb.volumeParam.ioVAtrb & ( softLockBit | hardLockBit )) != 0;
    }

Marshall Clow
Aladdin Systems
mclow@san_marcos.csusm.edu


+++++++++++++++++++++++++++

From [e-mail] (Jump Long)
Date: 4 Jun 1994 23:28:02 -0400
Organization: America Online, Inc. (1-800-827-6364)

In article <2sm3jr$[e-mail]>, [e-mail] (Roland
Kwee) writes:

>How do I quickly check if the volume is locked? New Inside Mac,
Files,
>p2-8 says I should check that before opening a file for write
access,
>because the file open call would return OK even on locked volumes.
>They recommend calling PBHGetVInvo() (what a user-friendly
system...)
>which is described on p. 2-144, but I can't find the description
>of the volume attributes ioVAtrb.

>Does anybody know?

Funny you should ask. I added CheckVolLock to MoreFiles (the DTS File
Manager sample) this afternoon.  Here's the prototype, documentation,
and function. The only code not included here is the pcpy function
which I'm sure you can come up with (or grab it from MoreFiles).

/********************************************************************
*********/

pascal OSErr CheckVolLock(StringPtr pathname,
        short vRefNum);
/* Use CheckVolLock to determine if a volume is locked - either by
 hardware or by software. If CheckVolLock returns noErr, then the
volume
 is not locked.

 pathName input: Pointer to a full pathname or nil.  If you pass in a

      partial pathname, it is ignored. A full pathname to a
      volume must end with a colon character (:).
 vRefNum  input: Volume specification (volume reference number,
working
      directory number, drive number, or 0).
*/

/********************************************************************
*********/

pascal OSErr CheckVolLock(StringPtr pathname,
        short vRefNum)
{
 HParamBlockRec pb;
 Str255 tempPathname;
 OSErr error;

 pb.volumeParam.ioVRefNum = vRefNum;
 if (pathname == nil) {
  pb.volumeParam.ioNamePtr = nil;
  pb.volumeParam.ioVolIndex = 0;  /* use ioVRefNum only */
 }
 else {
  pcpy((StringPtr)tempPathname, pathname); /* make a copy of the
string and */
  pb.volumeParam.ioNamePtr = (StringPtr)tempPathname; /* use the copy
so original isn't trashed */
  pb.volumeParam.ioVolIndex = -1; /* use ioNamePtr/ioVRefNum
combination */
 }
 error = PBHGetVInfoSync(&pb);

 if ( error == noErr )
 {
  if ( (pb.volumeParam.ioVAtrb & 0x0080) != 0 )
   error = wPrErr;  /* volume locked by hardware */
  else if ( (pb.volumeParam.ioVAtrb & 0x8000) != 0 )
   error = vLckdErr; /* volume locked by software */
 }

 return (error);
}

/********************************************************************
*********/

- Jim Luther


---------------------------

End of C.S.M.P. Digest
**********************